|
Das Transaktionsprinzip hat sich im Datenbankbereich
bew"ahrt,da nur wenige Daten angefa"st werden und die
kontrollierten Arbeitseinheiten klein sind, also die Verweilzeit im
System kurz ist. Jedoch lassen sich langlebige Abl"aufe
(Workflows) auf einem Computersystem mit dem klassischen
Transaktionsmodell nicht verwirklichen. Beispielsweise ist eine
strikte alles-oder-nichts Semantik bei Vorg"angen, die Tage,
Monate oder Jahre dauern, nicht akzeptabel. Bei einem Fehlerfall
sollten nicht alle bisher ausgef"uhrten Aktivitäten
zur"uckgenommen werden, vielmehr sollte eine
anwendungsspezifische Fehlerbehandlung durchgef"uhrt werden
(Kompensation), die den bisherigen Arbeitsfortschritt
ber"ucksichtigt und nach der die Ausf"uhrung fortgesetzt
werden kann. Das ConTract Modell ist ein "erweitertes"
Transaktionsmodell zur zuverlässigen Abarbeitung von langlebigen,
verteilten Abl"aufen. Die Konzepte des ConTract Modells werden
in einer prototypischen Implementierung (APRICOTS) an der
Universit"at Stuttgart umgesetzt. Die Programmierung solcher
Abl"aufe kann nur durch eine grafische Programmierumgebung
sinnvoll unterst"utzt werden. Neben der eigentlichen Definition
des Kontroll- und Datenflusses eines Ablaufs spielen spezifische
Eigenschaften der Elemente eines ConTracts eine tragende Rolle.
Beispielsweise besitzen Steps (die auszuf"uhrenden
Aktivit"aten innerhalb eines Ablaufs) unterschiedliche
Parameter, die Variablen des Ablaufs zugeordnet werden m"ussen.
Dies trifft ebenso f"ur Transaktionen und
Kontrollflu"skonstrukte zu. Ziel dieser Arbeit ist es, Dialoge
f"ur die Zuordnung von Eigenschaften zu Elementen eines
ConTracts zu entwerfen und in den graphischen Editor zu integrieren.
Dazu m"ussen die einzelnen Elemente eines ConTracts analysiert
werden, d.h. die Eigenschaften (Struktur) der einzelnen
ConTract-Elemente, die ein Skriptprogrammierer zuweisen kann, und
die Relationen zwischen einzelnen Elementen m"ussen festgelegt
werden. Nach der Analyse eines ConTracts folgt der Entwurf von
Dialogen zur Eingabe von Eigenschaften der einzelnen
ConTract-Elemente. F"ur jede Eigenschaft bzw.
Eigenschaftsklasse m"ussen passende Interaktionsformen
er"ortert und ausgew"ahlt werden. Dabei sollen allgemeine
Richtlinien zur Dialoggestaltung auf einem Computersystem
ber"ucksichtigt werden. Ebenso wie im Falle der Definition des
Kontrollflusses mu"s daf"ur Sorge getragen werden,
da"s die Korrektheit der Eigenschaften bereits durch die
Dialoge selbst "uberpr"uft wird. Beispielsweise mu"s
"uberpr"uft werden, ob ein Step, der in den Ablauf
aufgenommen wird, auch definiert ist. Weiterhin soll darauf geachtet
werden, da"s die Kommunikation mit weiteren Werkzeugen
m"oglich ist (Schnittstellen zu weiteren Komponenten) und
Erweiterungen der Eigenschaften von Elementen einfach aufgenommen
werden k"onnen. Neben der Korrektheit bei der Eingabe der
Eigenschaften soll die Konsistenz der Daten ebenfalls durch die
Dialogkomponete gesichert werden. Beispielsweise sollten alle
ung"ultigen Referenzen auf Elemente, die aus einem Skript
gel"oscht wurden, invalidiert werden.
|